@dcodeIO I also added some tests from tc39/test262 and found one issue. Plz don't merge this yet

Ok. Now should be more right. I switched to approach for handling Pow10 as in RapidJSON with division on significand / pow10(-exp) when exp is negative instead multiply it to negative power from LUT. This approach don't loose precision in some rare cases.

cc @dcodeIO
plz review it again)

It ready to re-review

Regarding these failure cases: How bad is this practically? Are these merely edge cases? What do other standard libraries do?

It has only corner cases for extremely large or small values. To improve this cases we should choose much more complex solution which I'll definitely implement later. But this solution is pretty enought for most cases. See this comment. And this affect only when x < ~1e-22 || x >= ~1e40. We have potentially wrong 2 last decimal digits

I see, thanks. So this is due to limiting to 64 bits for intermediate values, right? If so, tempted to say that this might be as good as it gets at this point in time anyway, since emulating 128 bit floats without multi-value looks like it'd need a shadow stack / heap support anyway. Even if metallic did that with structs, we'd probably still want to use multi-value (2 x 64 bits passed via the execution stack).

128-bit soft floats usually slower than 128-bit fixed points. So 128-bit modular algos much better and use for such cases pretty widely for double <-> string conversion and trig argument reduction (Payne Hanek approach for large arguments). But in case with double <-> string probably BigFloat128 better solution

@dcodeIO Currently it's not absolutely ideal. I'll rewrite part for handling huge values but this require some refactoring because dtoa also based on same BigFloat routines so will be great unify all of this and the same time fix some mispricisions on dtoa. But could be done later I guess.

Thanks!